干货|字节跳动基于Flink SQL的流式数据质量监控(上)技术调研及选型
此前部分数据质量平台用户为了监控流式数据质量,选择将流式数据dump到hive,再对hive数据进行监控。但这种方式的实时性较差,若有数据质量问题,只能在T+1后报出。且对于很多流式任务的“中间”数据,原本不需要落地,为了监控而落到hive,存在着大量的资源浪费。
为更好地满足流式数据用户的数据质量监控需求,同时填补数据质量平台在流式数据源方面的空白,字节跳动数据质量平台团队于2020年下半年,以Kafka数据写入延迟监控为切入点,陆续调研、开发、上线了一系列基于Flink StreamSQL的流式数据质量监控。
本文为系列文章的上篇,重点介绍字节跳动数据质量平台技术调研及选型的思考。
DataLeap
产品调研Apache Griffin | M厂 | W厂 | D厂 | |
计算引擎 | Spark | Flink | Spark | Spark + deequ + delta lake |
主要技术实现 | 将流转为batch,基于batch数据做计算。 | Flink中两个窗口聚合。 | Spark收集审计数据,发到审计中心。 | 在spark streaming程序中,由deequ分析器对datafram做计算。 |
产品形态 | 配置化、平台化 | 平台化 | - | 提供SDK,需用户写代码,编写分析器。 |
调研主要结论
1、各产品的计算引擎均使用Spark或Flink,二者都能解决需求,在稳定性和性能上也没有显著的差异。实际上各产品在计算引擎选取方面,主要考虑的是已方的技术栈、技术积累、计算引擎与已方技术架构的融合度等。如D厂的主要业务是做Spark的商业化产品,引擎自然地使用Spark;M厂的相应产品产生的背景也是基于Flink在该厂的应用和推广。
2、除Apache Griffin由于采用了先流转批、再复用批处理能力的策略,指标产出延迟为分钟级外,其它指标产出延迟均为秒级。需注意的是指标产出延迟并非报警的延迟。实际报警的延迟时间还受所采用的报警引擎的触发方式、轮询执行周期等影响。
3、各产品均未由计算引擎直接触发报警,而是由计算引擎计算出对应的数据质量指标数据,存到下游sink后,再基于sink中的数据,检测及触发报警。同时还可基于sink中的数据提供灵活的报表、可视化服务。这其实是业内较为普遍的作法,即计算引擎只负责计算,后续监控和报警功能由专门的监控报警引擎负责。
DataLeap
选型Flink SQL
从性能上看,使用SQL API不会比使用DataStream API性能差。Flink SQL最终也会编译成Java代码执行,二者并无本质差别。
从功能上看,当前Flink SQL的语法已经很丰富,支持kafka、RocketMQ等常用流式数据源和MySQL、TSDB等sink。另外字节跳动Flink团队也会根据公司内用户的需求,开发一些定制化的功能,如支持kafka header数据字段等。Flink SQL能够满足大部分的流式数据质量监控的功能需求。
从使用友好程度上看,在进行规则配置转化时,SQL API相对DataStream API更友好,更易于实现,更便于调试。在增加新的流式监控类型和新feature时,开发人员主要需考虑如何拼SQL计算对应的监控指标,且可直接使用Dataleap数据开发平台的Flink SQL作业进行调试。另外,直接使用SQL API,更容易支持用户自定义SQL指标的监控规则。
产品介绍
火山引擎大数据研发治理套件DataLeap
一站式数据中台套件,帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设,帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。后台回复数字“2”了解产品
http://griffin.apache.org/docs/profiling.html
How to Monitor Data Stream Quality Using Spark Streaming and Delta Lake
https://github.com/awslabs/deequ
- End -